Two unrelated fixes, both from the same incident — a dev workspace hitting planLimitReached.

1. The integration tests were mis-budgeted, not flaky

test/integration/test/cli.extension-config.test.ts spawns the real prisma-composer binary — which resolves both /control entries and evaluates a config — and neither test set a timeout, so both inherited bun test's 5000ms default. Real CI runs take 5148ms and 5747ms.

So they failed roughly two runs in three across unrelated PRs, and the symptom hid the cause: the process is killed before it writes, so you get

Expected to contain: "no built entry at"
Received: ""
  ^ this test timed out after 5000ms

which reads as a broken CLI, not a budget. Now 30s — they cost ~1.7s locally, and CI is ~3× slower under contention.

Worse than the flake itself: neither Test nor the deploy canary is a required check, so this was a red check people learn to ignore.

run-alchemy.test.ts also failed once in the same run (Expected: 0, Received: 1). Deliberately not touched: it spawns a trivial fake script, runs in <1s across repeated runs, and a timeout would surface as signal set / status: null, not a clean non-zero exit. Adding a timeout there would paper over a cause we haven't found. Worth a look if it recurs.

2. destroy --production now removes the app's Project

destroy tore down a stack's resources but the Project survived forever, so hand-run stacks piled up as empty Projects until the workspace hit its plan limit. The CI sweeper can't help — it only runs against CI's own workspace and only matches ^<prefix>-ci-\d+$.

This mirrors the Branch cleanup one level up: destroy --stage already deletes its Branch after a successful alchemy destroy (relying on the API refusing to delete a Branch with live members). So destroy --production now deletes its Project, with the API's own refusal as the guard.

Cleanup is best-effort and never throws — the destroy already succeeded, and failing the command over a cleanup step would be worse than leaving a shell:

The API contract differs from the assumption going in. I expected a 409, mirroring Branch delete. It isn't: deleteV1ProjectsById answers 204/400/401/404 — there's no 409 in that operation's schema at all; only branch delete has one. Verified against @prisma/management-api-sdk's types, and consistent with the existing postgres/Project.ts resource. So 400 is the kept case.

Users can observe this, so per .agents/rules/user-facing-surface-changes.mdc it lands in docs/guides/deploying.md and the skill in this PR.

Tests

• container.test.ts — deleteProject issues the DELETE, tolerates 404, surfaces other errors.
• ensure-containers.test.ts — success, 404, 400 keeps the Project and does not throw, other errors warn, missing token warns. The 400 case was mutation-checked: making it throw fails the test; reverted, green.
• run.test.ts — --production deletes the Project; --stage never touches it; a failed destroy skips it; deploy never touches it.
• Fixed a regression this surfaced in four pre-existing --production tests that had no deleteProject seam and no token, so the real function's warning broke a not.toHaveBeenCalled() assertion.

Green: lowering 103, CLI 95, integration 2 (1.6s/1.7s). Typecheck, lint:deps, biome clean. No live deploy run.

🤖 Generated with Claude Code